訂單系統原本只支援全額退款，已收款訂單的付款狀態會從「已付款」變成「已退款」。這次新增部分退款，讓客服可以退回部分款項，付款狀態也增加「部分退款」，原本的「已退款」則繼續表示全額退回。

退款金額、交易紀錄、API與畫面，是這次直接需要修改的地方。但系統裡還有一支每天產生售後追蹤名單的排程，其中一項篩選條件是付款狀態為「已付款」。它沒有參與退款流程，卻依賴退款後的狀態來決定哪些訂單應該被追蹤，因此也在這次變更的影響範圍內。

這份名單的用途，是追蹤仍保留有效購買的客戶；部分退款後仍有保留商品的訂單，也應納入。付款狀態細分之後，排程若維持原條件，這些訂單反而會從名單消失。

同一個狀態判斷，可能代表不同目的

在只有全額退款的情況下，排程可以用「已付款」篩選仍保留購買的訂單。現在多了部分退款，原本的條件就不再完整。依這份名單的規則，除了原有條件，也要納入仍有有效購買的部分退款訂單。

但另一個查詢頁籤的用途，是列出「已收款且尚未退款」的訂單。它原本也篩選「已付款」，卻不應因為新增狀態，就把部分退款一起放進來。

兩個地方使用相同的狀態值，不代表它們需要相同的修改。前者借用付款狀態辨認追蹤資格，後者則是在精確查詢付款情形。新狀態出現後，需要回到各自的用途，確認原本的判斷是否仍然成立。

因此，把所有「已付款」條件一起改成「已付款或部分退款」，範圍可能過大；只修改退款入口與畫面，範圍又可能不足。這裡的合理範圍，取決於哪些既有行為需要維持。

找到使用位置，還不等於知道怎麼改

搜尋狀態列舉、查詢條件與資料對應，可以找出可能受影響的位置。但找到使用位置後，還要確認它用這個狀態判斷什麼，才能決定是否需要修改。

例如售後排程需要調整篩選，付款查詢頁籤應保留原條件，訂單詳情則需要呈現新的狀態文字。同樣使用付款狀態，處理方式卻不同。

這些依賴也不一定都在目前的專案裡。排程可能獨立維護，報表可能直接查資料庫，其他服務則透過API接收付款狀態。即使沒有直接呼叫退款功能，只要使用它更新後的資料，就可能受到影響。

因此，只搜尋網頁與API的程式還不夠，也要對照相關專案、資料使用文件與執行紀錄。月底才執行的報表，不會因為最近一天沒有呼叫紀錄就不受影響；影響範圍要沿著資料的使用方式追查，不能停在這次修改的專案邊界。

修改多一點或少一點，都需要理由

釐清各個入口的用途後，就能決定哪些地方需要調整，哪些應該保留。售後排程雖然沒有參與退款操作，仍需要修改才能維持原本的追蹤資格；「尚未退款」頁籤即使使用相同狀態，也不應一起放寬條件。

因此，修改範圍不能只看檔案數量。多改一支排程，可能是在補足必要影響；少改一個查詢，則可能是在保留正確行為。每項修改與保留，都應能對應到具體的業務用途。

合理的修改範圍，不是改最少的程式，而是沿著資料與判斷的依賴，補齊必須連動的地方，同時保留不該改變的行為。理解既有狀態的真實用途，才能看懂每項修改為什麼需要，或為什麼不能亂動。

「這次只新增一個"部分退款"狀態，應該半天就能上線吧？」
「前端畫面改好了，API也支援了。」
「那售後追蹤的簡訊排程呢？」
「還是只認『已付款』。客戶退了一部分的錢，我們退掉了全部的關心。」